Font Garden

home *** CD-ROM | disk | FTP | other *** search

/ Font Garden / Font Garden (Walnut Creek) (October 1995) (1995).iso / pc / macutils / graphics / sparkle2 / _docs_ / new_in24.2 < prev next >

Wrap

Text File | 1995-06-19 | 41.2 KB | 708 lines

What's new in 2.4.2? • Bug fixes: In 2.4.1 the 68K version often didn't play. Damn uninitialized variable. • Now supports the .M15 and .M75 MPEG suffixes. Also uses a better guess for the frame rate when opening a movie with an invalid frame rate. • Revamped MPEG playback prefs dialog which removes obsolete options, adds a new option and is a little more cohesive. • Playback is slightly faster with half pixels off and about 7% faster with half pixels on. Essentially this means that the cost of using half pixels, is not much more than the cost of not using it. • Under certain rare conditions in previosu versions, the color conversion tables were destroyed too soon and images were displayed in random colors. I hope I have now fixed this. What's new in 2.4.1? • Yet more speed: 16bit playback is now more than THREE times as fast as it was. Playback of resized images is MUCH faster. NOTE: Some of the code changes I made to get this speed may well cause the code to run slower on 68K macs. I am not going to work hard to maintain two code bases for PPC and 68K. All my effort is going into optimal PPC speed, with no concern for 68K. As a result of the changes to make 16bit playback faster, two things are now a little different: (a) 16bit display in 16bit-fast mode is now higher quality (and the same as the hybrid 16/24 bit option which will go away when I fix the playback prefs dialog) (b) If you move the window across two screens image quality may be substantially reduced. I figure this doesn't matter much--you shouldn't do that anyway cause it causes so much slowdown. People interested in speed may be interested in the following: on my 7100/80 with an accelerated 24bit card, 40% (!!!!!) of time in 24bit playback is now spent copying data to the screen. This is why we need PCI and a faster bus!!! • Now that I have some extra speed at my disposal, I have altered some of the internal code (parsing and IDCT) to correctly handle some of the most finicky details of the MPEG spec. The result is to slow the code down by about 5% but, under certain circumstances, to improve the quality of the image somewhat. Now that I have the CPU to do a good job, I want to make the images Sparkel displays as good as possible, rather than the somewhat amateurish quality they have sometimes had. • Bug fixes to 2.4.0 * With 2.4.0 I switched to a new link system and forgot to weak link against SpeechLib. This caused problems for people without SpeechManager on their macs. Now fixed. * The PPC assembly I was using to build a 24bit pixmap worked OK for my video card but built a pixmap incompatible with the HPV motherboard video on PPCs. This should now be fixed. * There were a few typos in the PPC assembly I wrote for 2.4.0 resulting in occasionaly visual glitches in the image. These are fixed. • FINALLY: I now save the index Sparkle builds when it first opens an MPEG, saving the lengthy startup while the index is calculated. Along with this I now also allow a frame rate to be saved with the MPEG. This is especially useful for the common MPEGs floating around the internet that have been encoded with a non-standard MPEG rate like 6 or 8fps. Along with this comes a new menu item under the edit menu for stripping the resource fork from an MPEG. Read the ReadMe 2nd file for why you might want to do this. • Command-Y is now a shortcut for the Set Frame Rate menu item. • In the past sometimes error messages were not reported to the user because of a design flaw in the Think Class Library which I use to handle that sort of thing. (Gee, thanks, Symantec.) I have made some patches to TCL to try to rectify this---hopefully now you will always get an error message when something goes wrong (especially when opening files) rather than being left in the dark. • Backward realtime playback sometimes played frames out of order. No longer. • If both MPEG and QT movies were open and memory ran low, Sparkle could lock up. Fixed. • The user interface to the MPEGSplit app was slightly altered, to give better error message feedback, and to remove some confusion about what to do when an error occurs. What's new in 2.4.0? • Bug fix: I made a dumb error in 2.3.4 or 2.3.5. The symptons varied depending on your machine but most commonly were that if you grew the document larger than a certain size the window would go blank. • Bug fix: If you did some fiddling with the MPEG prefs, swapping bit depths and such, you could get your windows to become munged. This bug has been around for a year or so and no-one ever reported it (you have to do a very precise set of things to trigger it) but now it's gone. • Speed boost: I did profiling of the PPC code and based on that made some changes to the C code, as well as moving certain loop routines into PPC assembly. The resultant code can be as much as twice as fast as Sparkle 2.3.5 if everything is right. But not everything is in PPC yet---I only had time to do what I thought were the most common cases. In particular only the 4x4 IDCT is in PPC, not the 8x8 IDCT, and only 24bit display code is in PPC, not 8 or 16 bit code. Those will come in time. There are also some other major algorithmic modifications in the wings to boost speed, but those are further away. Also going to PPC assembly has meant the app is now built with a crazy quilt of Symantec C++ versions 7, 8 and Toolserver. The point is that I am poised to switch to using the very high quality (and phenomenally slow) C/C++ compilers from say Motorola at some point in the nearish future. With luck these would give a speed boost that's reasonable and yet easily achieved. What's new in 2.3.5? • I found that there are certain MPEGs floating around (examples are flower.mpg and byrncad.mpg) that are not unusually MPEG encoded. Specifically they contain a B-frame as the second frame, and it's not clear how the I-frame before that B-frame should be interpreted---as a past or as a future predictor. An MPEG like this would crash Sparkle, now it does not. Be warned, however, that the MPEGs I've seen like this are not very well encoded---it seems that the encoder used shows a general lack of knowledge of how MPEG frames are re-ordered when decoding, so the resultant MPEG can be pretty awful in areas where there is a lot of video motion. • Bug fix related to releasing memory when Sparkle is closed. • Sparkle does not work when Aladdin Shortcut (an INIT like Boomerang) is installed. As far as I can tell, this is a problem with Shortcut. I wrote to Aladdin a long time ago asking about this and never received a reply. I then wrote a few days ago and have not received a reply. If you use Shortcut and want this fixed, complain to Aladdin and tell them to speak to me. What's new in 2.3.4? • Misc bug fixes---mainly on rare occasions things were set up to trap to the debugger on an error. These situations are now invalidated for release builds. • MPEGSplitter 1.02 fixes: * Code for testing if volumes were locked or not is now more robust. * Code for selecting directories is more robust. * Quite a bit faster. What's new in 2.3.3? • Bug fix: Sparkle now runs OK without Speech Manager present (just like in 3.2.1 and earlier versions). • Bug fix: Sparkle was writing to memory location 4 during startup. The problem was some variables were being initailzed in the wrong order. This caused a message for people who had LOBE installed. What's new in 2.3.2? • The new code for auto arranging windows when new files are opened wasn't quite correct. Now fixed. • Many people asked if I could return to picture based MPEG and QT encoding (as opposed to time based encoding). To satisfy everyone I now support both. To get time based encoding, choose a frame rate of zero when encoding MPEGs or movies. (On the latest versions of QT a frame rate of 0 is called Best in the popup list). Also any frame rate is supported for MPEG encoding. Be aware, however, that by choosing a frame rate not supported by the MPEG standard you are creating an MPEG file that may not play on all MPEG decoders, especially those based on special purpose hardware. • QT encoding using a specified data rate (only possible with the Cinepak encoder) didn't work correctly. Now fixed. If you have a PowerMac I would recommend using this option. What's new in 2.3.1? • The bug where opening some MPEgs gave an error -2014 is fixed. • Sound now works with looping. • MPEG encoder bugs fixed: * For sources that are not a multiple of 16 in width and height, motion vectors could go in the range between the real height/width and the height/width rounded up to a multiple of 16, which is not allowed by the DIS. (Every other encoder I know also screws up this way, but we might as well get it right.) * When skipping macroblocks in P & B pictures, DC DCT coefficients weren't being reset to midgrey. * When skipping macroblocks in P pictures, motion vectors were not being reset to zero. * Half pixels now work again (by mistake I had disabled them in 2.3.0). • The code for auto arranging windows across screens when you open a new document has been changed. This new code is a little more flexible and I hope it'll be more likely to come up with optimal placements of new windows. • The progress bar now flips down automatically when you're encoding then hides itself once encoding is done. • The way low memory situations are reported has been changed. This should work a little better with QT. Let me know if it behaves strangely. • Selecting portions of a movie is now supported. Select a portion of a movie using the shift key in conjunction with the mouse button or arrow keys. You can use a selection for two purposes: * You can limit playback to within the selection. * Only the selection will be used when creating a new QT/MPEG movie. What's new in 2.3? • The MEG2Decoder had problem where it screwed up display of MPEGs that were not a multiple of 16 in width. Fixed • A serious problem with MPEGEncoding that often produced garbage MPEGs is fixed. • All encoding (QT and MPEG) is now done based on time. not frame number. This makes audio support much easier. • Preliminary audio support has been added for MPEGs. See the ``Readme Sound'' file for details. • Opening QT movies (especially long ones) is faster. • Some minor user interface tweaks. • Some cosmetic bugs fixed. • You can now choose the frame rate at which to play MPEGs and PICT pseudo-movies. What's new in 2.2.3? • Bug fixes: * Under certain circumstances an MPEG would stop playing just before the very last or first frame was displayed. • Speed tweaks. What's new in 2.2.1? • Bug fixes: * In very special circumstances (a slightly corrupt MPEG that was missing a SequenceEndCode, I was writing a few bytes over the end of a memory block. This lead to crashes on 020/030 class macs. * When encoding an MPEG, I (very stupid, I know) landed up aliasing the file reference number associated with the MPEG file, then closing that fileReferenceNumber twice, something Apple warn is not a great idea. * At startup if the user had a corrupt prefs file and tried to quit, Sparkle would crash---I was ForgetHandle()ing a resource handle. Grrr! * Fixed Yet Another problem with the SC++ BEL macros. This one involved crummy Symantec code for testing if an object's on the stack that fails when threads are active. * Was setting the bkPixPat of a window to NULL when closing it--dumb. * Was disposing of a handle that was disposed of in some library code written by someone else. Taligent have a nice naming convention for libraries to prevent this sort of thing---it can't happen a moment too soon. * Fixed a few anomalies I noticed in the way things are drawn on 1 and 2 bit screens (like anyone uses Sparkle on one :-) ). • Tweaks to make the progam feel snappier: * Wherever I was calling FlushVol() to dump the disk cache to disk, I now do that asynchronously. Async IO is also used in a few other places. It's not yet used for reading files, but that will come. Note that QuicKeys, for reasons that (I'll be charitable and not state my true feelings) make no sense to me, disables asynchronous IO so you won't see any effect. If you think this sucks, call CE Software and tell them. * I now preload QuickTime stuff at startup to avoid latencies later when I need it. * When building a PICT pseudo-movie, a much faster algorithm for scanning for the files of the movie is used. * When displaying a PICT pseudo-movie, the disk should be accessed rather less often than before • MPEG encoding has been sped up. I have dropped the Berkeley encoding algorithms and used my own algorithms. (Where these are similar to the Berkeley algorithm, I use the same name simply for consistency.) My algorithms are not only faster but produce slightly smaller files and use more elegant, shorter code---a perfect win win win situation. The Technical Readme file contains brief descriptions of the properties of the new algorithms. What's new in 2.2? • The usual cleanups of course. • Substantially improved building of the index when an MPEG is opened. The new code is about five times the speed of the old code, and the interleaving of CPU and file access is done more carefully. This should make windows popup more snappily when you open an MPEG file. (Unfortunately if you're pulling the MPEG off a slow hard drive, CD-ROM or network this speed is limited anyway by the file system, not the CPU calculations.) • I should have had a TRY/CATCH handler in place for if an error occurred while the dialog boxes were being popped up for saving an MPEG or QT movie. This could have led to crashes (more likely just strange error dialogs), but is now fixed. • If you ran Sparkle in the background on an 8-bit color screen while a foreground app kept creating a number of different palettes, then when Sparkle was quit an error message could occur (I was running down an array associated with each new palette destroying items but I should have run down the array starting from the end not the beginning of the array.) • Thread synchronization is now done ``properly'' using a number of semaphores. This replaces the old method of using a very carefully orchestrated dance to move between threads. The new method is theoretically safer (and makes it a lot easier to alter the code) but being new I may have forgotten something in one routine or two. Bear with me and report any strange bugs---machine locking up, strange error messages, garbled images. • Some (very strange) QT movies may have multiple superimposed video tracks. In this case when Sparkle created an MPEG or QT movie from the original QT movie parts of the image you saw could have random colors in them. This is now fixed. • Other strange QT movies could be encoded with not a fixed frame rate but every frame lasting a different amount of time. When creating an MPEG nothing can be done about that, but when creating a new QT movie I allow a frame rate of zero which will create all frames at whatever time they should be created at. • When a movie was being encoded to some other format the movie controller was not drawn with all decorations suppressed. Now it is. • When an MPEG window was opened said window displayed some flicker as pieces of it were drawn. This has been cleaned up. Likewise for PICT-sequence windows. • In a few places certain variables that should gave been initialized to NULL or zero were not. In theory if an exception ocurred in these blocks of code a crash might occur. Anyway now fixed. • A bug in CustomGetFile() in the MacOS leads to a loss of 64 (or so) bytes every time a file selection dialog box is displayed if there is an `ictb' associated with the dialog box. (It looks like the `ictb' is read in and DetachResource'd() then the handle created that way is never disposed of.) This was fixed by removing the `ictb's associated with these dialogs. The same holds true for `mctb's if the dialog contains a popupmenu. I would guess it also holds for `cctb's, but it does NOT hold for `dctb's. • New look---windows with grey background, can shrink video as small as you like. a startup splash screen. • If you decide partway through startup you don't want to run Sparkle, hit command-. (command-period) to abort. • PowerMac native (and very fast). A 6100/60 gives three times the playback rate of my Quadra 610. • Rewritten MPEG encoder to use way less memory. • MPEG decoding code has been restructured so as to present a block of code that can easily be dropped into other environments. This will form the basis for various QT components/drivers I'd like to write to give much tighter integration with QT. • All large memory allocation is done through temp mem. Basically this means you shouldn't ever need to increase the size of Sparkle's partition but you can open and save files limited only by all the memory on your mac. • Foundations have been laid for AppleScripting. You probably can't do any useful scripting with this release but that will change soon. • User interface has been tweaked a little. I hope you like the changes. • The most common problem with the 2.1 versions was that the preferences file would become corrupted leading to random errors. The prefs file handling has been changed in this version to make that much less likely. If this release gives you problems, destroy the Sparkle prefs file then try again. • Many many bug fixes. What's new in 2.1.5? • Somewhere in the cleanups of code of the last few revs I landed up dividing some color motion vectors by two too often resulting in misaligned color on MPEGs created without half-pixels. This is fixed. What's new in 2.1.4? • Many many internal cleanups of the code as part of my cleanup for PowerPC. If these cleanups broke anything, please tell me. • There was in bug in some earlier versions so that when you opened Sparkle on a system without QuickTime rather than quitting gracefully it could crash when quitting. Now fixed. • Minor changes have been made to better support Macintosh Easy Open. • When saving an MPEG or QT movie in an alternative form the play button of the movie controller is hidden which I think looks better. • When a movie saving was in progress and was paused, if the relevant window was covered then uncovered (generating an update event) Sparkle would hang. This was because Sparkle tries to switch to a thread that has been put to sleep. This has been fixed. • If an MPEG were opened and immediately command-S were typed, once the saving was done it was possible for Sparkle to popup an error message. The problem was that the very first update event for the MPEG window, used to initialize some variables, would be discarded is a save were begun immediately. The code used when an MPEG is opened has been fiddled a little to prevent this. • I was asked by some people doing Sparkle for batch conversion of MPEG and QT for a way for Sparkle to indicate when it is done converting a file. I won't have AppleScriptability in place for a few months but I did put in a quick hack to allow this for users of QuicKeys. Look in the ReadMe 2nd file for details (do a search for QuicKeys). • In the code I added to 2.1.3 to support halfPixels I made a typo which under rare circumstances would set the color of a block incorrectly or (if you were unlucky) crash. This is fixed. • Memory used for MPEG encoding MPEGs has been dramatically reduced. For the case of encoding MPEGs with only I-frames, the memory required is 1/6th of what was required in 2.1.3 and earlier versions. For MPEGs using P and/or B frames, memory required is about .4 of what required earlier (actually 15/36). These memory requirements will be shrunk further in later versions of the code. • The MPEG Playback prefs dialog has cleaned up a little and behaves a little more intuitively. Now the options under the 8bit color section always apply when the screen is 8bit color, regardless of the 8bit dithering method used. There is now a tryout button. Click there to see how the changes you make alter what you see. • Two further options have been added to the MPEG Encoding dialog to give you a little more control over this behavior. You can now specify whether half-pixel encoding is used or not (in the past half-pixels were always used). Likewise you can specify whether or not to compare against raw reference frames or reference frames decoded from the MPEG stream being created (in the past decoded reference frames were always used). What's new in 2.1.3? • There was a bug in 2.1.2 that prevented one (usually) from playing MPEGs in play all frames mode. So sorry about that. This is fixed. • I have (FINALLY) fiddled the P and B frame calculations to be EXACT at highest quality settings (ie when saving an MPEG to a secondary file.) The last few touches involved doing all the finicky details specified in the MPEG DIS (which in the worst case can involve compositing a single image point from values spread over nine different places. The differences are very subtle but are visible---large areas of smooth texture in particular in the past tended to develop a slight granularity which is now cured. This code involved coding a huge number of special cases and I may have made a mistake in a case or two. I have run all my example MPEGs through and they look good but if you see a block that looks misaligned or has a different color from what it should have, please tell me so I know I need to fix a mistake. • There was a bug in 2.1.2 and earlier versions where, if an MPEG was playing and you closed the window there was a small chance of an error message popping up. This bug was due to what's called a race condition. It should have been fixed, but if not please tell me. What's new in 2.1.2? • In 2.1 when a window was first opened and the Video menu selected, the menu showed Palindrome looping as on even though it was not. This is fixed. • In 2.1 I had a serious (crashing) possible bug that could occur when a window was closed. This was because the life cycles of video encoding threads and video playing threads are different. I must rationalize these to one model, but till then I've applied a quick and dirty fix. • Long complicated pathways through about six auxiliary functions, used when threads died and a holdover from the Sparkle 1.x days, have been removed to use a much simpler virtual function based scheme. This is slightly faster and, more important, much simpler hence, hopefully, less buggy. • Deactivating/activating of the ``Change file type to MPEG'' radio button in the open file dialog was a little erratic. This has been fixed. • Rudimentary balloon help has been added. • When memory is very low and a window starts being opened, but fails partway, the cleanup code was slightly wrong. Now fixed. • Improved the display on 4-bit color screens. It was very blocky. • Changed the progressbar to display properly on 4-bit color screens. The two colors used for foreground and background were being mapped onto the same color. • Change the progress bar to update itself better when parts of the window are uncovered. Before parts would be drawn quite a while before other parts giving a result that looked silly. • Added a menu option to allow operation without ever yielding time to WaitNextEvent. If you don't need to give time to background applications, use this option for faster, less jerky, playback. • Speech manager code used to announce a delay when encoding an MPEG could, if timing was just wrong, crash. I think the problem was that the Speech Manager was building internal data structures on the stack, and that stack disappeared when the the MPEG encoding thread died. Anyway I've modified the speech code so this can't happen. • Discovered a serious problem in my video encoding code. When an MPEG window was resized while it was being converted to another MPEG or QT movie, the result could be a munged image for a few frames. The fix involved a major structural readjustment of Sparkle---ALL video manipulations now pass through ThreadEvent queues---but the result is that for the first time I feel confident about the theoretical underpinnings of Sparkle---that while minor bugs may remain, there are no conceptual nasties waiting to bite me. • When windows are resized, the resizing is done in a manner that leaves no gunk in the window in the moments before the resizing is complete. • I discovered yet another way in which things could crash---The MacOS call DrawPicture() will crash if it runs out of memory---thanks Apple. There's nothing I can do about this, so what I did do is try to trap situations that form a pattern of using DrawPicture() while memory is getting lower and warn you that memory is running low. This doesn't catch all situations but catches some. • The play/pause button no longer toggles between states when you start a movie saving or pause it. This is because what I was doing to get this to work in QT 1.x no longer works nicely in QT 2.0 --- flickering frames result. I guess this is a consequence of DataPipe or something. Anyway I've replaced this with indicators in the title bar. • I made a few changes to allow easier more sensible playback of QT movies that consist of only sound. This is at present rudimentary but is a start. What's new in 2.1? • Yet again memory management has been fiddled with. Previous tinkering with memory management was to ensure that my own code never crashed for lack of memory. Building on top of that, I've tried to ensure that calls to the operating system won't crash for lack of memory. This is more difficult because, obviously, I don't know just what the memory requirements of each call are. However I've done the best I can, and the resultant code seems even more robust than 2.02. • The scheduling has been revamped based on the threading. I now make intelligent decisions about which thread to schedule when. Also calls to the main event loop, which were very expensive in time, have been cut dramatically. the result is about a 15% speed boost all round. • MPEG playback is now based on genuine timing, not on simply playing every frame as fast as possible. Like QuickTime movies, you can play MPEGs back in real time or play every frame. I also now support the movie controller variable speed controls obtained by control-clicking on the forward/backward stepper buttons. • You can now set QT and MPEG movies to loop. • You can now grow or shrink MPEG and QT movie windows. • The cursor is now hidden when movie playback starts, until you move it. This seems to be a reasonable compromise for preventing flickering cursor when starting a movie using the keyboard, but atill allows the user easily to find the cursor when needed. • When files are opened, windows are now tiled in a vaguely intelligent fashion, attempting both to use the available screens with best depth, and to avoid window overlap. • Dragging windows is now aligned to a grid of optimal window placement. This gives better movie playback. • Can now show/hide the progressPane, movie controller and frame count with the tab key using tab, shift-tab, control-tab. • The drawing of the progress bar has been altered slightly, to fix cosmetic defects and to make the appearance closer to that of the movie controller. • Support for MPEGs with a pixel aspect ratio not equal to one has been added. At present this isn't switched on because some dumb MPEGs out there have a bogus aspect ratio encoded in them. However if someone wants this feature right away, I'll add a user interface to access it. • Support for MPEGs with multiple sequence headers has been added, not that I have ever seen such an MPEG. • Playback is now much faster through a variety of mechanisms. However this has, as a consequence, lower quality playback. You may set through preferences which optimizations you're willing to accept for faster playback and which you're not willing to accept. All optimizations are turned off when converting an MPEG to another format so that you'll get the best possible quality. Playback speed is now about 1.6 times faster for 24 bit screens, about 2.5 times as fast for 8 bit grey screens, and improvements in between for other screen depths. • Special purpose display code is used for 24 bit, 16 bit and 8 bit color screens and 8 bit grey screens. All other screens are sent through one of the above special purpose codes then use QuickTime to convert the pictures to the appropriate screen depth. Obviously special purpose code is faster. If I get lots of calls for screen depths other than the one's I'v supported directly, I'll look into adding more special purpose code. • In 2.0 I broke the support for adding files called name.mpg, but without a file type of MPEG so you could open files of that type but nothing would happen. Sorry about that. It's been fixed. • When files are opened and are not of the default Mac types (for example files imported from a UNIX box, or files on a PC CD ROM) Sparkle uses more intelligence in deciding whether to open these files as MPEGs, QT movies or pictures. If this mechanism is still not general enough for some users (I image mainly users sharing data with PCs), let me know. • The ``official'' MPEG encoding pattern of IBBPBBPBBPBB is now a pre-defined option. Some people asking for this as a pre-defined option have given me slightly different patterns as the ``official'' pattern. However what I have used is, to the best of my knowledge correct, and I'm assuming these people who wrote to me simply made typos. If you have comments on this, please mail me. • I twiddled the RGB to YCrCB conversion code that is the first step in encoding MPEGs. The changes won't affect anyone except people creating MPEG movies whose width or height is odd, in which case the very last row or column of pixels will have more accurate color. The important change, however, was that I no longer read beyond the end of some arrays, so I'm ready for when Apple give us protected memory a year from now. • Under certain rare circumstances, depending on the number of frames int the input file and the IPB pattern used, the last frame or two of the input would not be saved in the output MPEG. This is fixed. • MPEG encoding now can specify a frame rate (in the past this was always 30 fps). Sure the range of choices is limited---blame the people who wrote the MPEG spec---those are, basically, the only choices. 1) Can people with MPEG hardware verify that this works for me? On my mac with 10fps max playback, it's tough to see if this works. 2) There are some frame rates I've omitted that are very close to those I give, for example 29.97 fps. At some point i'll get the finicky time right to support these but it's a pretty low priority compared to sound. What's new in 2.01? • Implemented padding YUV macroblocks with a repeat of the last value of each YUV triplet when macroblocks at the edge of a frame spill over the edge. The most common case of this is a 120 pixel high movie with a macroblock height of 128. In the past this spillover was filled randomly. The result of this is that MPEGs created are about 15% smaller. • Some diddling with the code used by the IDCT algorithm gives a speed boost of about 5% to both playing and encoding MPEGs. • Fixed a serious bug that prevented you from playing an MPEG if you started playing it then interrupted it. A nice byproduct of this is that I got jogging of MPEGs fully operational. You can now repeatedly view a section of the MPEG by hitting command-right-arrow then command-left-arrow to keep the MPEG moving forwards then backwards. • Altered the alert popped up when the Thread Manager is not present to make it more palatable to corporate and institutional users. • Fixed the MPEG buffering which would give problematic results for very small MPEGs (say three frames or less). • Finally went through all resources, marking them purgable or not and removing the unnecessary ones. • Fixed the "PBBIBB" default frame set to make it correspond to the user view of things, not my programmer's view. • Fixed a bug that prevented a temporary movie created by the movie controller handling an MPEG file from being destroyed. • Fixed two bugs in the Think Class Library dealing with the loading of dialogs then manipulating them without setting their memory blocks to non-purgable. • Fixed a long-standing bug in the MPEG player buffer-handling code that would cause the MPEG frame index to be incorrect if it was created while memory was short. This probably never caused problems except for very long MPEGs. • When converting a QT movie into a different movie form, the dialog that comes up asking you for compression options will have the frame rate and key frame rate set at what the original movie used, sparing you from having to guess. I will eventually have this working across all file conversions, not just movie-->movie. • The Think C 6 compiler contains a bug when performing code-motion optimization on complex loops. If you run through the assembly it produces in this case, it performs some very nifty register coloring and creating induction variables for the loop. It then leaves out one crucial instruction to update one of the induction variables each pass through the loop and so the code is garbage. As far as I can tell, this only affects one function in my code and I have used a #pragma there to prevent it happening, but the fact that bugs like this exist in the compiler is a little worrying. • Revised all memory allocation so that it is more likely to not to use up all memory reserves and leave nothing for toolbox. • Found an especially nasty bug involving grabbing frames from a QT movie which, when memory ran low, would leave the system GrafPort/GDevice environment in an inconsistent state. • Revised all uses of GWorld to use tempMem, but fallback to local heap if tempMem is unavailable. • Altered the strings used to popup error messages at startup if QuickTime is not available. These got mixed up when I moved code around. • The code to build the MPEG index when an MPEG is opened would run out of space when a very large MPEG was opened---one of a thousand frames or more. Now memory is allocated for this a little more flexibly. • Fixed a bug I inserted when I changed from Sparkle 1.6 to 1.7. I rewrote the Berkeley motion vector code to speed it up and in the process made one little typo, shifting a variable right by 1 not 2. The effect of this, in Sparkles 1.7 and 2.0 was that, under very rare occasions, blocks of color would appear a few pixels off from where they should be. The only place I ever saw this was three or four frames of the MPEG sales110.mpg. This is not related to a separate problem. The motion estimation code in the MPEG encoder (at present the Berkeley code with practially no changes) is not perfect. It sometimes creates blocks that appear to be wildly off from where they should be (by quite a few pixels). This is not very obvious in real life, but is very obvious in animation. This is largely a quantization artifact---it goes away if you lower the quantizations. But obviosly you don't want to do that always, just where necessary, so you really want a smarter quantizer that is adaptive. I'll work on issues like this as soon as I can. • When converting a movie with sound to MPEG or QT, occasionally pops of sound could be heard. This is fixed. • When converting movies with very low keyframe rates (say 20 or more dependent frames per keyframe) occasionally the display of the movie would get confused and appear to alternate between two different frames. This is fixed. What's new in 2.0? • The structure of the code has been completely altered to be based on threads. This makes it much easier for me to add new features to the code while having it retain MultiFinder friendliness. • Now opens and plays QT movies. • Now can create MPEG files. General conversion from {QT or MPEG}--->{QT or MPEG} is possible. • Many minor changes to the way files are opened, named and such. • Makes minor use of the speech manager if installed. • You can now play MPEGs backwards. What's new in 1.71? • The progress bar now updates itself properly at the very end of saving each frame to Quicktime. It also draws itself better on b/w screens. • More of the default QT movie player keystrokes now work. • The app notes if an MPEG file has many errors and if so warns you that it has probably been transferred to the mac incorrectly. • I have incorporated a workaround to make Sparkle work with the QT VM extension. However I do not recommend you use the two together. If you do use QT VM you will find Sparkle's memory usage a little less efficient than without using QT VM. This is because of the way QT VM works. • Fixed a bug that caused unusually sized MPEGs to display as distorted. • Sparkle should now cope a little better with low memory situations. • Added a small tweak to improve drawing on 16bit screens under low memory conditions. • Uses the most recently released version on the floating windoid. • I have learned of an app that will convert QT to MPEG on the mac. It's not the easiest thing to use and I recommend this only for people who really need this, not for people who just want to play around. See the README file for details. What's new in 1.7? • Opening files is much faster. • Fixed the size of the checkboxes in the Open File dialog to the correct size for all those millions of people who use Chicago as their system font cause they have no sense of aesthetics. Oops. • Now when Sparkle changes the file-type of an file, the Finder will update the icon immediately, instead of forcing you to open and close the folder to see a new icon. Thanks to Jamie McCarthy for telling me how to do this. • Added an "About Sparkle" dialog box to quieten the constant stream of complaints about this. • Changed the way progress is reported. I think the new scheme feels rather more elegant. (If you have a fast machine and only use small MPEGs, you may not notice this change much.) • Adde random access. You can now use the step backward stepper, or simply click in movie controller where you want to go. All standard movie controller clicks and keystrokes are supported. • Restructured the internal code vastly. This is what took most of the time and while it doesn't directly help you users, it gives me a framework that's much easier to build on. For example it should be trivial to add Apple Event support when I get round to that. • Three or four minor bugs were squelched, mostly involving Sparkle crashing when it encountered MPEGs with invalid data in them. • Now quits gracefully when started on a 68000 mac like a Classic, rather than crashing. I'm sure lots of people care about this. • Added better multi-tasking support. This takes two forms. One is that the length of the timeslices Sparkle uses before giving up the CPU are now absolute times. Before they were numbers that worked well for my SE/30, but probably not optimally for slower or faster machines. The second is that you can now context switch out of Sparkle while it is doing slow QT conversions (especially converting to Compact Video). The way I have implemented this is not wonderful, but the best I can do given the present way the code is structured. The next version will use the Thread Manager and will do this rather better. This second form of timeslicing is done through the SetSequenceProgressProc() call which is new in QT1.6 and which is why I now require use of QT1.6. Also QT does not yield the CPU very often, and (as far as I know) there is no way to make it yield more often. So while your machine is no longer completely frozen as it does its conversion, it's still not too pleasant to use for typing. I can't do much about this---complain to Apple and tell them to change this part of QT, or better yet the whole OS. What's new in 1.6? • I became tired of continually having to explain to people about mac file types, so I wrote a file filter function for the Open File dialog box which displays ALL files with a .mpg suffix. This should make use a lot easier for novices. • Fixed a bug that involved writing to NULL. • Fixed a bug that prevented IBP type MPEGs from rewinding when they reached the end and the play button was hit twice. What's new in 1.5.2? • I was disposing of a handle twice (specifically I was disposing of a pixmap and then its colortable, not realizing that DisposPixMap took care of the colortable for me.) Thanks to Dan Sears for pointing this out. I never noticed a problem due to this bug, but it's probably good to have killed it. Whats new in 1.5.1? • One part of my speed optimizing code was not being initialized properly. This caused a very specific type of MPEG file to show parts of its first frame as greenish blobs. Now fixed. • The code to detect errors in a corrupted MPEG file has been made even more robust. Substantially better recovery from such errors, by rebuilding the lost parts of a frame from the previous frame, has been introduced. Thanks to a wonderfully corrupt MPEG file I pulled off usenet with about 15 misc errors in it for pointing out new and ingenious ways to fail. • New icons, courtesy of Richard Lim in Britain. I hope you like them. You will have to rebuild the desktop to see them.